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Abstract 


This document specifies interworking between the Session Initiation 
Protocol (SIP) and QSIG within corporate telecommunication networks 
(also known as enterprise networks). SIP is an Internet 
application-layer control (signalling) protocol for creating, 
modifying, and terminating sessions with one or more participants. 
These sessions include, in particular, telephone calls. QSIG is a 
signalling protocol for creating, modifying, and terminating 
circuit-switched calls (in particular, telephone calls) within 
Private Integrated Services Networks (PISNs). QSIG is specified in a 
number of Ecma Standards and published also as ISO/IEC standards. 
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Les 


Introduction 


This document specifies signalling interworking between QSIG and the 
Session Initiation Protocol (SIP) in support of basic services within 
a corporate telecommunication network (CN) (also known as enterprise 
network). 


QSIG is a signalling protocol that operates between Private 
Integrated Services eXchanges (PINX) within a Private Integrated 
Services Network (PISN). A PISN provides circuit-switched basic 
services and supplementary services to its users. QSIG is specified 
in Ecma Standards; in particular, [2] (call control in support of 
basic services), [3] (generic functional protocol for the support of 
supplementary services), and a number of standards specifying 
individual supplementary services. 


NOTE: The name QSIG was derived from the fact that it is used for 
Signalling at the Q reference point. The Q reference point is a 
point of demarcation between two PINXs. 


SIP is an application-layer protocol for establishing, terminating, 
and modifying multimedia sessions. It is typically carried over IP 
[15], [16]. Telephone calls are considered a type of multimedia 
session where just audio is exchanged. SIP is defined in [10]. 


As the support of telephony within corporate networks evolves from 
circuit-switched technology to Internet technology, the two 
technologies will coexist in many networks for a period, perhaps 
several years. Therefore, there is a need to be able to establish, 
modify, and terminate sessions involving a participant in the SIP 
network and a participant in the QSIG network. Such calls are 
supported by gateways that perform interworking between SIP and QSIG. 


This document specifies SIP-QSIG signalling interworking for basic 
services that provide a bi-directional transfer capability for 
speech, DTMF, facsimile, and modem media between a PISN employing 
QSIG and a corporate IP network employing SIP. Other aspects of 
interworking, e.g., the use of RTP and SDP, will differ according to 
the type of media concerned and are outside the scope of this 
specification. 


Call-related and call-independent signalling in support of 
supplementary services is outside the scope of this specification, 
but support for certain supplementary services (e.g., call transfer, 
call diversion) could be the subject of future work. 
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Interworking between QSIG and SIP permits a call originating at a 
user of a PISN to terminate at a user of a corporate IP network, or a 
call originating at a user of a corporate IP network to terminate at 
a user of a PISN. 


Interworking between a PISN employing QSIG and a public IP network 
employing SIP is outside the scope of this specification. However, 
the functionality specified in this specification is in principle 
applicable to such a scenario when deployed in conjunction with other 
relevant functionality (e.g., number translation, security functions, 
etc.). 


This specification is applicable to any interworking unit that can 
act as a gateway between a PISN employing QSIG and a corporate IP 
network employing SIP. 

2. Terminology 
In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and 
indicate requirement levels for compliant SIP implementations. 


3. Definitions 


For the purposes of this specification, the following definitions 
apply. 


3.1. External Definitions 
The definitions in [2] and [10] apply as appropriate. 

3.2. Other definitions 

3.2.1. Corporate Telecommunication Network (CN) 
Sets of privately-owned or carrier-provided equipment that are 
located at geographically dispersed locations and are interconnected 


to provide telecommunication services to a defined group of users. 


NOTE: A CN can comprise a PISN, a private IP network (intranet), or a 
combination of the two. 
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3.2.2. Gateway 


An entity that performs interworking between a PISN using QSIG and an 
IP network using SIP. 


3.2.3. IP Network 
A network (unless otherwise stated, a corporate network) offering 
connectionless packet-mode services based on the Internet Protocol 
(IP) as the network-layer protocol. 

3.2.4. Media Stream 
Audio or other user information transmitted in UDP packets, typically 
containing RTP, in a single direction between the gateway and a peer 


entity participating in a session established using SIP. 


NOTE: Normally a SIP session establishes a pair of media streams, one 
in each direction. 


3.2.5. Private Integrated Services Network (PISN) 


A CN or part of a CN that employs circuit-switched technology. 


3.2.6. Private Integrated Services Network Exchange (PINX) 


A PISN nodal entity comprising switching and call handling functions 
and supporting QSIG signalling in accordance with [2]. 


4. Acronyms 


DNS Domain Name Service 

IP Internet Protocol 

PINX Private Integrated services Network eXchange 
PISN Private Integrated Services Network 

RTP Real-time Transport Protocol 

SCTP Stream Control Transmission Protocol 


SDP Session Description Protocol 
SIP Session Initiation Protocol 
TCP Transmission Control Protocol 
TLS Transport Layer Security 

TU Transaction User 

UA User Agent 


UAC User Agent Client 
UAS User Agent Server 
UDP User Datagram Protocol 
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3% 


Background and Architecture 


During the 1980s, corporate voice telecommunications adopted 
technology similar in principle to Integrated Services Digital 
Networks (ISDN). Digital circuit switches, commonly known as Private 
Branch eXchanges (PBX) or more formally as Private Integrated 
services Network eXchanges (PINX) have been interconnected by digital 
transmission systems to form Private Integrated Services Networks 


(PISN). These digital transmission systems carry voice or other 
payload in fixed-rate channels, typically 64 Kbit/s, and signalling 
in a separate channel. A technique known as common channel 


signalling is employed, whereby a single signalling channel 
potentially controls a number of payload channels or bearer channels. 
A typical arrangement is a point-to-point transmission facility at Tl 
or El rate providing a 64 Kbit/s signalling channel and 23 or 30 
bearer channels, respectively. Other arrangements are possible and 
have been deployed, including the use of multiple transmission 
facilities for a signalling channel and its logically associated 
bearer channels. Also, arrangements involving bearer channels at 
sub-64 Kbit/s have been deployed, where voice payload requires the 
use of codecs that perform compression. 


OSIG is the internationally-standardized message-based signalling 
protocol for use in networks as described above. It runs ina 
signalling channel between two PINXs and controls calls on a number 
of logically associated bearer channels between the same two PINXs. 
The signalling channel and its logically associated bearer channels 
are collectively known as an inter-PINX link. QSIG is independent of 
the type of transmission capabilities over which the signalling 
channel and bearer channels are provided. QSIG is also independent 
of the transport protocol used to transport QSIG messages reliably 
over the signalling channel. 


QSIG provides a means for establishing and clearing calls that 
originate and terminate on different PINXs. A call can be routed 
over a single inter-PINX link connecting the originating and 
terminating PINX, or over several inter-PINX links in series with 
switching at intermediate PINXs known as transit PINXs. A call can 
originate or terminate in another network, in which case it enters or 
leaves the PISN environment through a gateway PINX. Parties are 
identified by numbers, in accordance with either [17] or a private 
numbering plan. This basic call capability is specified in [2]. In 
addition to basic call capability, QSIG specifies a number of further 
capabilities supporting the use of supplementary services in PISNs. 


More recently, corporate telecommunications networks have started to 
exploit IP in various ways. One way is to migrate part of the 
network to IP using SIP. This might, for example, be a new branch 
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office with a SIP proxy and SIP endpoints instead of a PINX. 
Alternatively, SIP equipment might be used to replace an existing 
PINX or PINXs. The new SIP environment needs to interwork with the 
OSIG-based PISN in order to support calls originating in one 
environment and terminating in the other. Interworking is achieved 
through a gateway. 


Interworking between QSIG and SIP at gateways can also be used where 
a SIP network interconnects different parts of a PISN, thereby 
allowing calls between the different parts. A call can enter the SIP 
network at one gateway and leave at another. Each gateway would 
behave in accordance with this specification. 


Another way of connecting two parts of a PISN would be to encapsulate 
QSIG signalling in SIP messages for calls between the two parts. 

This is outside the scope of this specification but could be the 
subject of future work. 


This document specifies signalling protocol interworking aspects of a 
gateway between a PISN employing QSIG signalling and an IP network 
employing SIP signalling. The gateway appears as a PINX to other 
PINXs in the PISN. The gateway appears as a SIP endpoint to other 


SIP entities in the IP network. The environment is shown in Figure 
1. 
Ho + IP network PISN 
| | 
SIP ene i 
Proxy | / | | 
| | / |PINx | 
+---+--+ ko + / | 
| | | +----- +/  +------ + 
| | | | | 
| | | ae | 
E E Tenas E +: Gateway Focs cnie 
| | | | | |\ 
| | | | t-----+ \ 
| | | | \ +------ + 
| | | | \| | 
+--+---+ 4+--+---+ Ko + PINX 
| SIP | SIP 
|End- | |End- | +------ + 
|point | |point | 
+------ + +------ + 


Figure 1: Environment 
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In addition to the signalling interworking functionality specified in 
this specification, it is assumed that the gateway also includes the 
following functionality: 


- one or more physical interfaces on the PISN side supporting one or 
more inter-PINX links, each link providing one or more constant bit 
rate channels for media streams and a reliable layer 2 connection 
(e.g., over a fixed rate physical channel) for transporting QSIG 
signalling messages; and 


- one or more physical interfaces on the IP network side supporting, 
through layer 1 and layer 2 protocols, IP as the network layer 
protocol and UDP [6] and TCP [5] as transport layer protocols, 
these being used for the transport of SIP signalling messages and, 
in the case of UDP, also for media streams; 


- optionally the support of TLS [7] and/or SCTP [9] as additional 
transport layer protocols on the IP network side, these being used 
for the transport of SIP signalling messages; and 


- a means of transferring media streams in each direction between the 
PISN and the IP network, including as a minimum packetization of 
media streams sent to the IP network and de-packetization of media 
streams received from the IP network. 


NOTE: [10] mandates support for both UDP and TCP for the transport of 
SIP messages and allows optional support for TLS and/or SCTP for this 
same purpose. 


The protocol model relevant to signalling interworking functionality 
of a gateway is shown in Figure 2. 
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4----------------------- +--------- $----------------------- + 
| | | | 
| SIP | | | 
| | | | 
+----------------------- + | | 
UDP/TCP/TLS/SCTP | QSIG 

| | | 
Ho oo + | | 
| | | | 
| IP | | | 
| | | | 
$----------------------- - Ho + 
| IP network | | PISN | 
| lower layers | | lower layers | 
| | | | 
$----------------------- + $----------------------- - 


Figure 2: Protocol model 


In Figure 2, the SIP box represents SIP syntax and encoding, the SIP 
transport layer, and the SIP transaction layer. The Interworking 
function includes SIP Transaction User (TU) functionality. 


6. Overview 


The gateway maps received QSIG messages, where appropriate, to SIP 
messages and vice versa and maintains an association between a QSIG 
call and a SIP dialog. 


A call from QSIG to SIP is initiated when a QSIG SETUP message 
arrives at the gateway. The QSIG SETUP message initiates QSIG call 
establishment, and an initial response message (e.g., CALL 
PROCEEDING) completes negotiation of the bearer channel to be used 
for that call. The gateway then sends a SIP INVITE request, having 
translated the QSIG called party number to a URI suitable for 
inclusion in the Request-URI. The SIP INVITE request and the 
resulting SIP dialog, if successfully established, are associated 
with the QSIG call. The SIP 2xx response to the INVITE request is 
mapped to a QSIG CONNECT message, signifying answer of the call. 
During establishment, media streams established by SIP and SDP are 
connected to the bearer channel. 
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A call from SIP to QSIG is initiated when a SIP INVITE request 
arrives at the gateway. The gateway sends a QSIG SETUP message to 
initiate QSIG call establishment, having translated the SIP Request- 
URI to a number suitable for use as the QSIG called party number. 

The resulting QSIG call is associated with the SIP INVITE request and 
with the eventual SIP dialog. Receipt of an initial QSIG response 
message completes negotiation of the bearer channel to be used, 
allowing media streams established by SIP and SDP to be connected to 
that bearer channel. The QSIG CONNECT message is mapped to a SIP 200 
OK response to the INVITE request. 


Appendix A gives examples of typical message sequences that can 
arise. 


7. General Requirements 


In order to conform to this specification, a gateway SHALL support 
QSIG in accordance with [2] as a gateway and SHALL support SIP in 
accordance with [10] as a UA. In particular, the gateway SHALL 
support SIP syntax and encoding, the SIP transport layer, and the SIP 
transaction layer in accordance with [10]. In addition, the gateway 
SHALL support SIP TU behaviour for a UA in accordance with [10] 
except where stated otherwise in Sections 8, 9, and 10 of this 
specification. 


NOTE: [10] mandates that a SIP entity support both UDP and TCP as 
transport layer protocols for SIP messages. Other transport layer 
protocols can also be supported. 


The gateway SHALL also support SIP reliable provisional responses in 
accordance with [11] as a UA. 


NOTE: [11] makes provision for recovering from loss of provisional 
responses (other than 100) to INVITE requests when using unreliable 
transport services in the IP network. This is important for ensuring 
delivery of responses that map to essential QSIG messages. 


The gateway SHALL support SDP in accordance with [8] and its use in 
accordance with the offer/answer model in [12]. 


Section 9 also specifies optional use of the Privacy header in 
accordance with [13] and the P-Asserted-Identity header in accordance 
with [14]. 


The gateway SHALL support calls from QSIG to SIP and calls from SIP 
to OSIG. 
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8. 


8. 


SIP methods not defined in [10] or [11] are outside the scope of this 
specification but could be the subject of other specifications for 
interworking with QSIG, e.g., for interworking in support of 
supplementary services. 


As a result of DNS lookup by the gateway in order to determine where 
to send a SIP INVITE request, a number of candidate destinations can 
be attempted in sequence. The way in which this is handled by the 
gateway is outside the scope of this specification. However, any 
behaviour specified in this document on receipt of a SIP 4xx or 5xx 
final response to an INVITE request SHOULD apply only when there are 
no more candidate destinations to try or when overlap signalling 
applies in the SIP network (see 8.2.2.2). 


Message Mapping Requirements 
1. Message Validation and Handling of Protocol Errors 


The gateway SHALL validate received QSIG messages in accordance with 
the requirements of [2] and SHALL act in accordance with [2] on 
detection of a QSIG protocol error. The requirements of this section 
for acting on a received QSIG message apply only to a received QSIG 
message that has been successfully validated and that satisfies one 
of the following conditions: 


-the QSIG message is a SETUP message and indicates a destination in 
the IP network and a bearer capability for which the gateway is able 
to provide interworking; or 


-the OSIG message is a message other than SETUP and contains a call 
reference that identifies an existing call for which the gateway is 
providing interworking between QSIG and SIP. 


The processing of any valid QSIG message that does not satisfy any of 
these conditions is outside the scope of this specification. Also, 
the processing of any QSIG message relating to call-independent 
signalling connections or connectionless transport, as specified in 
[3], is outside the scope of this specification. 


If segmented OSIG messages are received, the gateway SHALL await 
receipt of all segments of a message and SHALL validate and act on 
the complete reassembled message. 


The gateway SHALL validate received SIP messages (requests and 
responses) in accordance with the requirements of [10] and SHALL act 
in accordance with [10] on detection of a SIP protocol error. 
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Requirements of this section for acting on a received SIP message 
apply only to a received message that has been successfully validated 
and that satisfies one of the following conditions: 


- the SIP message is an INVITE request that contains no tag parameter 
in the To header field, does not match an ongoing transaction 
(i.e., is not a merged request; see Section 8.2.2.2 of [10]), and 
indicates a destination in the PISN for which the gateway is able 
to provide interworking; or 


- the SIP message is a request that relates to an existing dialog 
representing a call for which the gateway is providing interworking 
between OSIG and SIP; or 


- the SIP message is a CANCEL request that relates to a received 
INVITE request for which the gateway is providing interworking with 
QSIG but for which the only response sent is informational (1xx), 
no dialog having been confirmed; or 


- the SIP message is a response to a request sent by the gateway in 
accordance with this section. 


The processing of any valid SIP message that does not satisfy any of 
these conditions is outside the scope of this specification. 


NOTE: These rules mean that an error detected in a received message 
will not be propagated to the other side of the gateway. However, 
there can be an indirect impact on the other side of the gateway, 
e.g., the initiation of call clearing procedures. 


The gateway SHALL run QSIG protocol timers as specified in [2] and 
SHALL act in accordance with [2] if a QSIG protocol timer expires. 
Any other action on expiry of a OSIG protocol timer is outside the 
scope of this specification, except that if it results in the 
clearing of the QSIG call, the gateway SHALL also clear the SIP call 
in accordance with Section 8.4.5. 


The gateway SHALL run SIP protocol timers as specified in [10] and 
SHALL act in accordance with [10] if a SIP protocol timer expires. 
Any other action on expiry of a SIP protocol timer is outside the 
scope of this specification, except that if it results in the 
clearing of the SIP call, the gateway SHALL also clear the QSIG call 
in accordance with Section 8.4.5. 
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8.2. Call Establishment from QSIG to SIP 


8.2.1. Call Establishment from QSIG to SIP Using En Bloc Procedures 


The following procedures apply when the gateway receives a QSIG SETUP 
message containing a Sending Complete information element or the 
gateway receives a QSIG SETUP message and is able to determine that 
the number in the Called party number information element is 
complete. 


NOTE: In the absence of a Sending Complete information element, the 
means by which the gateway determines the number to be complete is an 
implementation matter. It can involve knowledge of the numbering 
plan and/or use of inter-digit timer expiry. 


8.2.1.1. Receipt of QSIG SETUP Message 


On receipt of a QSIG SETUP message containing a number that the 
gateway determines to be complete in the Called party number 
information element, or containing a Sending complete information 
element and a number that could potentially be complete, the gateway 
SHALL map the QSIG SETUP message to a SIP INVITE request. The 
gateway SHALL also send a QSIG CALL PROCEEDING message. 


The gateway SHALL generate the SIP Request-URI, To, and From fields 
in the SIP INVITE request in accordance with Section 9. The gateway 
SHALL include in the INVITE request a Supported header containing 
option tag 100rel, to indicate support for [11]. 


The gateway SHALL include SDP offer information in the SIP INVITE 
request as described in Section 10. It SHOULD also connect the 
incoming media stream to the user information channel of the inter- 
PINX link, to allow the caller to hear in-band tones or announcements 
and prevent speech clipping on answer. Because of forking, the 
gateway may receive more than one media stream, in which case it 
SHOULD select one (e.g., the first received). If the gateway is able 
to correlate an unselected media stream with a particular early 
dialog established using a reliable provisional response, it MAY use 
the UPDATE method [19] to stop that stream and then use the UPDATE 
method to start that stream again if a 2xx response is received on 
that dialog. 


On receipt of a QSIG SETUP message containing a Sending complete 
information element and a number that the gateway determines to be 
incomplete in the Called party number information element, the 
gateway SHALL initiate QSIG call clearing procedures using cause 
value 28, “invalid number format (address incomplete)". 
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If information in the QSIG SETUP message is unsuitable for generating 
any of the mandatory fields in a SIP INVITE request (e.g., if a 
Request-URI cannot be derived from the QSIG Called party number 
information element) or for generating SDP information, the gateway 
SHALL NOT issue a SIP INVITE request and SHALL initiate QSIG call 
clearing procedures in accordance with [2]. 


8.2.1.2. Receipt of SIP 100 (Trying) Response to an INVITE Request 


A SIP 100 response SHALL NOT trigger any QSIG messages. It only 
serves the purpose of suppressing INVITE request retransmissions. 


8.2.1.3. Receipt of SIP 18x provisional response to an INVITE request 


The gateway SHALL map a received SIP 18x response to an INVITE 
request to a QSIG PROGRESS or ALERTING message based on the following 
conditions. 


- If a SIP 180 response is received and no QSIG ALERTING message has 
been sent, the gateway SHALL generate a QSIG ALERTING message. The 
gateway MAY supply ring-back tone on the user information channel of 
the inter-PINX link, in which case the gateway SHALL include progress 
description number 8 in the QSIG ALERTING message. Otherwise the 
gateway SHALL NOT include progress description number 8 in the QSIG 
ALERTING message unless the gateway is aware that in-band information 
(e.g., ring-back tone) is being transmitted. 


- If a SIP 181/182/183 response is received, no QSIG ALERTING message 
has been sent, and no message containing progress description number 
1 has been sent, the gateway SHALL generate a QSIG PROGRESS message 
containing progress description number 1. 


NOTE: This will ensure that QSIG timer T310 is stopped if running at 
the Originating PINX. 


In all other scenarios, the gateway SHALL NOT map the SIP 18x 
response to a QSIG message. 


If the SIP 18x response contains a Require header with option tag 
100rel, the gateway SHALL send back a SIP PRACK request in accordance 
with [11]. 


8.2.1.4. Receipt of SIP 2xx Response to an INVITE Request 


If the gateway receives a SIP 2xx response as the first SIP 2xx 

response to a SIP INVITE request, the gateway SHALL map the SIP 2xx 
response to a OSIG CONNECT message. The gateway SHALL also send a 
SIP ACK request to acknowledge the 2xx response. The gateway SHALL 
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NOT include any SDP information in the SIP ACK request. If the 
gateway receives further 2xx responses, it SHALL respond to each in 
accordance with [10], SHOULD issue a BYE request for each, and SHALL 
NOT generate any further OSIG messages. 


Media streams will normally have been established in the IP network 
in each direction. If so, the gateway SHALL connect the media 
streams to the corresponding user-information channel on the inter- 
PINX link if it has not already done so and stop any local ring-back 
tone. 


If the SIP 2xx response is received in response to the SIP PRACK 
request, the gateway SHALL NOT map this message to any QSIG message. 


NOTE: A SIP 2xx response to the INVITE request can be received later 
on a different dialog as a result of a forking proxy. 


8.2.1.5. Receipt of SIP 3xx Response to an INVITE Request 


On receipt of a SIP 3xx response to an INVITE request, the gateway 
SHALL act in accordance with [10]. 


NOTE: This will normally result in sending a new SIP INVITE request. 


Unless the gateway supports the QSIG Call Diversion Supplementary 
Service, no QSIG message SHALL be sent. The definition of Call 
Diversion Supplementary Service for QSIG to SIP interworking is 
beyond the scope of this specification. 


8.2.2. Call Establishment from QSIG to SIP Using Overlap Procedures 
SIP uses en bloc signalling, and it is strongly RECOMMENDED to avoid 
using overlap signalling in a SIP network. A SIP/QSIG gateway 
dealing with overlap signalling SHOULD perform a conversion from 
overlap to en bloc signalling method using one or more of the 
following mechanisms: 

- timers; 


- numbering plan information; 


- the presence of a Sending complete information element in a 
received QSIG INFORMATION message. 


If the gateway performs a conversion from overlap to en bloc 


signalling in the SIP network, then the procedures defined in Section 
8.2.2.1 SHALL apply. 
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However, for some applications it might be impossible to avoid using 
overlap signalling in the SIP network. In this case, the procedures 
defined in Section 8.2.2.2 SHALL apply. 


8.2.2.1. En Bloc Signalling in SIP Network 
8.2.2.1.1. Receipt of QSIG SETUP Message 


On receipt of a QSIG SETUP message containing no Sending complete 
information element and a number in the Called party number 
information element that the gateway Cannot determine to be complete, 
the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message, start 
OSIG timer T302, and await further number digits. 


8.2.2.1.2. Receipt of OSIG INFORMATION Message 


On receipt of each QSIG INFORMATION message containing no Sending 
complete information element and containing a number that the gateway 
cannot determine to be complete, QSIG timer T302 SHALL be restarted. 
When QSIG timer T302 expires or a QSIG INFORMATION message containing 
a Sending complete information element is received, the gateway SHALL 
send a SIP INVITE request as described in Section 8.2.1.1. The 
Request-URI and To fields (see Section 9) SHALL be generated from the 
concatenation of information in the Called party number information 
element in the received QSIG SETUP and INFORMATION messages. The 
gateway SHALL also send a QSIG CALL PROCEEDING message. 


8.2.2.1.3. Receipt of SIP Responses to INVITE Requests 


SIP responses to INVITE requests SHALL be mapped as described in 
8.2.1. 


8.2.2.2. Overlap Signalling in SIP Network 


The procedures below for using overlap signalling in the SIP network 
are in accordance with the principles described in [18] for using 
overlap sending when interworking with ISDN User Part (ISUP). In 
[18], there is discussion of some potential problems arising from the 
use of overlap sending in the SIP network. These potential problems 
are applicable also in the context of OSIG-SIP interworking and can 
be avoided if overlap sending in the QSIG network is terminated at 
the gateway, in accordance with Section 8.2.2.1. The procedures 
below should be used only where it is not feasible to use the 
procedures of Section 8.2.2.1. 
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8.2.2.2.1. Receipt of QSIG SETUP Message 


On receipt of a QSIG SETUP message containing no Sending complete 
information element and a number in the Called party number 
information element that the gateway Cannot determine to be complete, 
the gateway SHALL send back a QSIG SETUP ACKNOWLEDGE message and 
start QSIG timer T302. If the QSIG SETUP message contains the 
minimum number of digits required to route the call in the IP 
network, the gateway SHALL send a SIP INVITE request as specified in 
Section 8.2.1.1. Otherwise, the gateway SHALL wait for more digits 
to arrive in QSIG INFORMATION messages. 


8.2.2.2.2. Receipt of OSIG INFORMATION Message 


On receipt of a QSIG INFORMATION message, the gateway SHALL handle 
the OSIG timer T302 in accordance with [2]. 


NOTE: [2] requires the QSIG timer to be stopped if the INFORMATION 
message contains a Sending complete information element or to be 
restarted otherwise. 


Further behaviour of the gateway SHALL depend on whether or not it 
has already sent a SIP INVITE request. If the gateway has not sent a 
SIP INVITE request and it now has the minimum number of digits 
required to route the call, it SHALL send a SIP INVITE request as 
specified in Section 8.2.2.1.2. If the gateway still does not have 
the minimum number of digits required, it SHALL wait for more QSIG 
INFORMATION messages to arrive. 


If the gateway has already sent one or more SIP INVITE requests, 
whether or not final responses to those requests have been received, 
it SHALL send a new SIP INVITE request in accordance with Section 3.2 
of [18]. The updated Request-URI and To fields (see Section 9) SHALL 
be generated from the concatenation of information in the Called 
party number information element in the received QSIG SETUP and 
INFORMATION messages. 


NOTE: [18] requires the new request to have the same Call-ID and the 
same From header (including tag) as in the previous INVITE request. 
[18] recommends that the CSeq header should contain a value higher 
than that in the previous INVITE request. 

8.2.2.2.3. Receipt of SIP 100 (Trying) Response to an INVITE Request 


The requirements of Section 8.2.1.2 SHALL apply. 
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8.2.2.2.4. Receipt of SIP 18x Provisional Response to an INVITE Request 
The requirements of Section 8.2.1.3 SHALL apply. 
8.2.2.2.5. Receipt of SIP 2xx Response to an INVITE Request 


The requirements of Section 8.2.1.4 SHALL apply. In addition, the 
gateway SHALL send a SIP CANCEL request in accordance with Section 
3.4 of [18] to cancel any SIP INVITE transactions for which no final 
response has been received. 


8.2.2.2.6. Receipt of SIP 3xx Response to an INVITE Request 
The requirements of Section 8.2.1.5 SHALL apply. 


8.2.2.2.7. Receipt of a SIP 4xx, 5xx, or 6xx Final Response to an 
INVITE Request 


On receipt of a SIP 4xx, 5xx, or 6xx final response to an INVITE 
request, the gateway SHALL send back a SIP ACK request. Unless the 
gateway is able to retry the INVITE request to avoid the problem 
(e.g., by supplying authentication in the case of a 401 or 407 
response), the gateway SHALL also send a QSIG DISCONNECT message 
(8.4.4) if no further QSIG INFORMATION messages are expected and 
final responses have been received to all transmitted SIP INVITE 
requests. 


NOTE: Further QSIG INFORMATION messages will not be expected after 
QSIG timer T302 has expired or after a Sending complete information 
element has been received. 


In all other cases, the receipt of a SIP 4xx, 5xx, or 6xx final 
response to an INVITE request SHALL NOT trigger the sending of any 
OSIG message. 


NOTE: If further OSIG INFORMATION messages arrive, these will result 
in further SIP INVITE requests being sent, one of which might result 
in successful call establishment. For example, initial INVITE 
requests might produce 484 (Address Incomplete) or 404 (Not Found) 
responses because the Request-URIs derived from incomplete numbers 
cannot be routed, yet a subsequent INVITE request with a routable 
Request-URI might produce a 2xx final response or a more meaningful 
4xx, 5xx, or 6xx final response. 
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8.2.2.2.8. Receipt of Multiple SIP Responses to an INVITE Request 
Section 3.3 of [18] applies. 

8.2.2.2.9. Cancelling Pending SIP INVITE Transactions 
As stated in Section 3.4 of [18], when a gateway sends a new SIP 


INVITE request containing new digits, it SHOULD NOT send a SIP CANCEL 
request to cancel a previous SIP INVITE transaction that has not had 


a final response. This SIP CANCEL request could arrive at an egress 
gateway before the new SIP INVITE request and trigger premature call 
clearing. 


NOTE: Previous SIP INVITE transactions can be expected to result in 
SIP 4xx class responses, which terminate the transaction. In Section 
8.2.2.2.5, there is provision for cancelling any transactions still 
in progress after a SIP 2xx response has been received. 


8.2.2.2.10. QSIG Timer T302 Expiry 


If QSIG timer T302 expires and the gateway has received 4xx, 5xx, or 
6xx responses to all transmitted SIP INVITE requests, the gateway 
SHALL send a QSIG DISCONNECT message. If T302 expires and the 
gateway has not received 4xx, 5xx, or 6xx responses to all 
transmitted SIP INVITE requests, the gateway SHALL ignore any further 
QSIG INFORMATION messages but SHALL NOT send a QSIG DISCONNECT 
message at this stage. 


NOTE: A QSIG DISCONNECT request will be sent when all outstanding SIP 
INVITE requests have received 4xx, 5xx, or 6xx responses. 


8.3. Call Establishment from SIP to QSIG 
8.3.1. Receipt of SIP INVITE Request for a New Call 


On receipt of a SIP INVITE request for a new call, if a suitable 
channel is available on the inter-PINX link, the gateway SHALL 
generate a QSIG SETUP message from the received SIP INVITE request. 
The gateway SHALL generate the Called party number and Calling party 
number information elements in accordance with Section 9 and SHALL 
generate the Bearer capability information element in accordance with 
Section 10. If the gateway can determine that the number placed in 
the Called party number information element is complete, the gateway 
MAY include the Sending complete information element. 


NOTE: The means by which the gateway determines the number to be 


complete is an implementation matter. It can involve knowledge of 
the numbering plan and/or use of the inter-digit timer. 
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The gateway SHOULD send a SIP 100 (Trying) response. 


If information in the SIP INVITE request is unsuitable for generating 
any of the mandatory information elements in a QSIG SETUP message 
(e.g., if a OSIG Called party number information element cannot be 
derived from SIP Request-URI field) or if no suitable channel is 
available on the inter-PINX link, the gateway SHALL NOT issue a QSIG 
SETUP message and SHALL send a SIP 4xx, 5xx, or 6xx response. If no 
suitable channel is available, the gateway should use response code 
503 (Service Unavailable). 


If the SIP INVITE request does not contain SDP information and does 
not contain either a Required header or a Supported header with 
option tag 100rel, the gateway SHOULD still proceed as above, 
although an implementation can instead send a SIP 488 (Not Acceptable 
Here) response, in which case it SHALL NOT issue a QSIG SETUP 
message. 


NOTE: The absence of SDP offer information in the SIP INVITE request 
means that the gateway might need to send SDP offer information in a 
provisional response and receive SDP answer information in a SIP 
PRACK request (in accordance with [11]) in order to ensure that tones 
and announcements from the PISN are transmitted. SDP offer 
information cannot be sent in an unreliable provisional response 
because SDP answer information would need to be returned in a SIP 


PRACK request. The recommendation above still to proceed with call 
establishment in this situation reflects the desire to maximise the 
chances of a successful call. However, if important in-band 


information is likely to be denied in this situation, a gateway can 
choose not to proceed. 


NOTE: If SDP offer information is present in the INVITE request, the 
issuing of a QSIG SETUP message is not dependent on the presence of a 
Required header or a Supported header with option tag 100rel. 
On receipt of a SIP INVITE request relating to a call that has 
already been established from SIP to QSIG, the procedures of 8.3.9 
SHALL apply. 

8.3.2. Receipt of QSIG CALL PROCEEDING Message 


The receipt of a QSIG CALL PROCEEDING message SHALL NOT result in any 
SIP message being sent. 
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3. Receipt of QSIG PROGRESS Message 


A QSIG PROGRESS message can be received in the event of interworking 
on the remote side of the PISN or if the PISN is unable to complete 
the call and generates an in-band tone or announcement. In the 
latter case, a Cause information element is included in the QSIG 
PROGRESS message. 


The gateway SHALL map a received QSIG PROGRESS message to a SIP 183 
(Session Progress) response to the INVITE request. If the SIP INVITE 
request contained either a Require header or a Supported header with 
option tag 100rel, the gateway SHALL include in the SIP 183 response 
a Require header with option tag 100rel. 


NOTE: In accordance with [11], inclusion of option tag 100rel ina 
provisional response instructs the UAC to acknowledge the provisional 
response by sending a PRACK request. [11] also specifies procedures 
for repeating a provisional response with option tag 100rel if no 
PRACK is received. 


If the QSIG PROGRESS message contained a Progress indicator 
information element with Progress description number 1 or 8, the 
gateway SHALL connect the media streams to the corresponding user 
information channel of the inter-PINX link if it has not already done 
so, provided that SDP answer information is included in the 
transmitted SIP response to the INVITE request or has already been 
sent or received. Inclusion of SDP offer or answer information in 
the 183 provisional response SHALL be in accordance with Section 
8.3.5. 


If the QSIG PROGRESS message is received with a Cause information 
element, the gateway SHALL either wait until the tone/announcement is 
complete or has been applied for sufficient time before initiating 
call clearing, or wait for a SIP CANCEL request. If call clearing is 
initiated, the cause value in the QSIG PROGRESS message SHALL be used 
to derive the response to the SIP INVITE request in accordance with 
Table 1. 


-4. Receipt of QSIG ALERTING Message 


The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) 
response to the INVITE request. If the SIP INVITE request contained 
either a Require header or a Supported header with option tag 100rel, 
the gateway SHALL include in the SIP 180 response a Require header 
with option tag 100rel. 
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NOTE: In accordance with [11], inclusion of option tag 100rel in a 
provisional response instructs the UAC to acknowledge the provisional 
response by sending a PRACK request. [11] also specifies procedures 
for repeating a provisional response with option tag 100rel if no 
PRACK is received. 


If the OSIG ALERTING message contained a Progress indicator 
information element with Progress description number 1 or 8, the 
gateway SHALL connect the media streams to the corresponding user 
information channel of the inter-PINX link if it has not already done 
so, provided that SDP answer information is included in the 
transmitted SIP response or has already been sent or received. 
Inclusion of SDP offer or answer information in the 180 provisional 
response SHALL be in accordance with Section 8.3.5. 


8.3.5. Inclusion of SDP Information in a SIP 18x Provisional Response 


When sending a SIP 18x provisional response to the INVITE request, if 
a QSIG message containing a Progress indicator information element 
with progress description number 1 or 8 has been received the gateway 
SHALL include SDP information. Otherwise, the gateway MAY include 
SDP information. If SDP information is included, it shall be in 
accordance with the following rules. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if SDP offer and answer information has 
already been exchanged, no SDP information SHALL be included in the 
SIP 18x provisional response. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if SDP offer information was received in 
the SIP INVITE request but no SDP answer information has been sent, 
SDP answer information SHALL be included in the SIP 18x provisional 
response. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if no SDP offer information was received 
in the SIP INVITE request and no SDP offer information has already 
been sent, SDP offer information SHALL be included in the SIP 18x 
provisional response. 


NOTE: In this case, SDP answer information can be expected in the SIP 
PRACK. 


If the SIP INVITE request contained neither a Required nor a 
Supported header with option tag 100rel, SDP answer information SHALL 
be included in the SIP 18x provisional response. 
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NOTE: Because the provisional response is unreliable, SDP answer 
information needs to be repeated in each provisional response and in 
the final SIP 2xx response. 


NOTE: If the SIP INVITE request contained no SDP offer information 
and neither a Required nor a Supported header with option tag 100rel, 
it should have been rejected in accordance with Section 8.3.1. 


8.3.6. Receipt of OSIG CONNECT Message 


The gateway SHALL map a QSIG CONNECT message to a SIP 200 (OK) final 
response for the SIP INVITE request. The gateway SHALL also send a 
QSIG CONNECT ACKNOWLEDGE message. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if SDP offer and answer information has 
already been exchanged, no SDP information SHALL be included in the 
SIP 200 response. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if SDP offer information was received in 
the SIP INVITE request but no SDP answer information has been sent, 
SDP answer information SHALL be included in the SIP 200 response. 


If the SIP INVITE request contained a Required or Supported header 
with option tag 100rel, and if no SDP offer information was received 
in the SIP INVITE request and no SDP offer information has already 
been sent, SDP offer information SHALL be included in the SIP 200 
response. 


NOTE: In this case, SDP answer information can be expected in the SIP 
ACK. 


If the SIP INVITE request contained neither a Required nor a 
Supported header with option tag 100rel, SDP answer information SHALL 
be included in the SIP 200 response. 


NOTE: Because the provisional response is unreliable, SDP answer 
information needs to be repeated in each provisional response and in 
the final 2xx response. 


NOTE: If the SIP INVITE request contained no SDP offer information 
and neither a Required nor a Supported header with option tag 100rel, 
it may have been rejected in accordance with Section 8.3.1. 
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The gateway SHALL connect the media streams to the corresponding user 
information channel of the inter-PINX link if it has not already done 
so, provided that SDP answer information is included in the 
transmitted SIP response or has already been sent or received. 


8.3.7. Receipt of SIP PRACK Request 


The receipt of a SIP PRACK request acknowledging a reliable 
provisional response SHALL NOT result in any QSIG message being sent. 
The gateway SHALL send back a SIP 200 (OK) response to the SIP PRACK 
request. 


If the SIP PRACK contains SDP answer information and a QSIG message 
containing a Progress indicator information element with progress 
description number 1 or 8 has been received, the gateway SHALL 
connect the media streams to the corresponding user information 
channel of the inter-PINX link. 


8.3.8. Receipt of SIP ACK Request 


The receipt of a SIP ACK request SHALL NOT result in any QSIG message 
being sent. 


If the SIP ACK contains SDP answer information, the gateway SHALL 
connect the media streams to the corresponding user information 
channel of the inter-PINX link if it has not already done so. 


8.3.9. Receipt of a SIP INVITE Request for a Call Already Being 
Established 


A gateway can receive a call from SIP using overlap procedures. This 
should occur when the UAC for the INVITE request is a gateway from a 
network that employs overlap procedures (e.g., an ISUP gateway or 
another OSIG gateway) and the gateway has not absorbed overlap. 


For a call from SIP using overlap procedures, the gateway will 
receive multiple SIP INVITE requests that belong to the same call but 
have different Request-URI and To fields. Each SIP INVITE request 
belongs to a different dialog. 


A SIP INVITE request is considered to be for the purpose of overlap 
sending if, compared to a previously received SIP INVITE request, it 
has: 


- the same Call-ID header; 


- the same From header (including the tag); 
- no tag in the To header; 
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- an updated Request-URI from which can be derived a called party 
number with a superset of the digits derived from the previously 
received SIP INVITE request; 


and if 


- the gateway has not yet sent a final response other than 484 to 
the previously received SIP INVITE request. 


If a gateway receives a SIP INVITE request for the purpose of overlap 
sending, it SHALL generate a QSIG INFORMATION message using the call 
reference of the existing QSIG call instead of a new QSIG SETUP 
message and containing only the additional digits in the Called party 
number information element. It SHALL also respond to the SIP INVITE 
request received previously with a SIP 484 Address Incomplete 
response. 


If a gateway receives a SIP INVITE request that meets all of the 
conditions for a SIP INVITE request for the purpose of overlap 
sending except the condition concerning the Request-URI, the gateway 
SHALL respond to the new request with a SIP 485 (Ambiguous) response. 


8.4. Call Clearing and Call Failure 


8.4.1. Receipt of a QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE 
Message 


On receipt of QSIG DISCONNECT, RELEASE, or RELEASE COMPLETE message 
as the first QSIG call clearing message, gateway behaviour SHALL 
depend on the state of call establishment. 


1) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE 
request and received a SIP ACK request, or if it has received a 
SIP 200 (OK) response to a SIP INVITE request and sent a SIP ACK 
request, the gateway SHALL send a SIP BYE request to clear the 
call. 


2) If the gateway has sent a SIP 200 (OK) response to a SIP INVITE 
request (indicating that call establishment is complete) but has 
not received a SIP ACK request, the gateway SHALL wait until a SIP 
ACK is received and then send a SIP BYE request to clear the call. 


3) If the gateway has sent a SIP INVITE request and received a SIP 


provisional response but not a SIP final response, the gateway 
SHALL send a SIP CANCEL request to clear the call. 
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NOTE 1: In accordance with [10], if after sending a SIP CANCEL 
request a SIP 2xx response is received to the SIP INVITE request, 
the gateway will need to send a SIP BYE request. 


4) If the gateway has sent a SIP INVITE request but received no SIP 
response, the gateway SHALL NOT send a SIP message. If a SIP 
final or provisional response is subsequently received, the 
gateway SHALL then act in accordance with 1, 2, or 3 above, 
respectively. 


5) If the gateway has received a SIP INVITE request but not sent a 
SIP final response, the gateway SHALL send a SIP final response 
chosen according to the cause value in the received QSIG message 


as specified in Table 1. SIP response 500 (Server internal error) 
SHALL be used as the default for cause values not shown in 
Table 1. 


NOTE 2: It is not necessarily appropriate to map some QSIG cause 
values to SIP messages because these cause values are meaningful only 
at the gateway. A good example of this is cause value 44, "Requested 
circuit or channel not available", which signifies that the channel 
number in the transmitted QSIG SETUP message was not acceptable to 
the peer PINX. The appropriate behavior in this case is for the 
gateway to send another SETUP message indicating a different channel 
number. If this is not possible, the gateway should treat it either 
as a congestion situation (no channels available; see Section 8.3.1) 
or aS a gateway failure situation (in which case the default SIP 
response code applies). 


In all cases, the gateway SHALL also disconnect media streams, if 


established, and allow QSIG and SIP signalling to complete in 
accordance with [2] and [10], respectively. 
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Table 1: Mapping of QSIG Cause Value to SIP 4xx-6xx responses to an 
INVITE request 


QSIG Cause value SIP response 
1 Unallocated number 404 Not found 
2 No route to specified 404 Not found 
transit network 
3 No route to destination 404 Not found 
16 Normal call clearing (NOTE 3) 
17 User busy 486 Busy here 
18 No user responding 408 Request timeout 
19 No answer from the user 480 Temporarily unavailable 
20 Subscriber absent 480 Temporarily unavailable 
21 Call rejected 603 Decline, if location field 
in Cause information element 
indicates user. Otherwise: 
403 Forbidden 
22 Number changed 301 Moved permanently, if 
information in diagnostic field 
of Cause information element is 
suitable for generating a SIP 
Contact header. Otherwise: 
410 Gone 
23 Redirection to new 410 Gone 
destination 
27 Destination out of order 502 Bad gateway 
28 Address incomplete 484 Address incomplete 
29 Facility rejected 501 Not implemented 
31 Normal, unspecified 480 Temporarily unavailable 
34 No circuit/channel 503 Service unavailable 
available 
38 Network out of order 503 Service unavailable 
41 Temporary failure 503 Service unavailable 
42 Switching equipment 503 Service unavailable 
congestion 
47 Resource unavailable, 503 Service unavailable 
unspecified 
55 Incoming calls barred 403 Forbidden 
within CUG 
57 Bearer capability not 403 Forbidden 
authorized 
58 Bearer capability not 503 Service unavailable 
presently available 
65 Bearer capability not 488 Not acceptable here (NOTE 4) 
implemented 
69 Requested facility not 501 Not implemented 
implemented 
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70 Only restricted digital 488 Not acceptable here (NOTE 4) 
information available 

79 Service or option not 501 Not implemented 
implemented, unspecified 

87 User not member of CUG 403 Forbidden 

88 Incompatible destination 503 Service unavailable 

102 Recovery on timer expiry 504 Server time-out 


NOTE 3: A QSIG call clearing message containing cause value 16 will 
normally result in the sending of a SIP BYE or CANCEL request. 
However, if a SIP response is to be sent to the INVITE request, the 
default response code should be used. 


NOTE 4: The gateway may include a SIP Warning header if diagnostic 
information in the QSIG Cause information element allows a suitable 
warning code to be selected. 


8.4.2. Receipt of a SIP BYE Request 


On receipt of a SIP BYE request, the gateway SHALL send a QSIG 
DISCONNECT message with cause value 16 (normal call clearing). The 
gateway SHALL also disconnect media streams, if established, and 
allow QSIG and SIP signalling to complete in accordance with [2] and 
[10], respectively. 


NOTE: When responding to a SIP BYE request, in accordance with [10], 
the gateway is also required to respond to any other outstanding 
transactions, e.g., with a SIP 487 (Request Terminated) response. 
This applies in particular if the gateway has not yet returned a 
final response to the SIP INVITE request. 


8.4.3. Receipt of a SIP CANCEL Request 


On receipt of a SIP CANCEL request to clear a call for which the 
gateway has not sent a SIP final response to the received SIP INVITE 
request, the gateway SHALL send a QSIG DISCONNECT message with cause 
value 16 (normal call clearing). The gateway SHALL also disconnect 
media streams, if established, and allow QSIG and SIP signalling to 
complete in accordance with [2] and [10], respectively. 


8.4.4. Receipt of a SIP 4xx-6xx Response to an INVITE Request 


Except where otherwise specified in the context of overlap sending 
(8.2.2.2), on receipt of a SIP final response (4xx-6xx) to a SIP 
INVITE request, unless the gateway is able to retry the INVITE 
request to avoid the problem (e.g., by supplying authentication in 
the case of a 401 or 407 response), the gateway SHALL transmit a QSIG 
DISCONNECT message. The cause value in the QSIG DISCONNECT message 
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SHALL be derived from the SIP 4xx-6xx response according to Table 2. 
SHALL be used as the default for 
The gateway SHALL also 


Cause value 31 
SIP responses not shown in Table 2. 
disconnect media streams, 
signalling to complete in accordance with [2] 


When generating a QSIG Cause information element, 
SHOULD contain the value 
response code 6xx, 
user" 


(Normal, 


"user", 


in other circumstances. 


unspecified) 


if established, 


and allow QSIG and SIP 
and [10], respectively. 


the location field 


if generated as a result of a SIP 
or the value "Private network serving the remote 


Table 2: Mapping of SIP 4xx-6xx responses to an INVITE request to 
QSIG Cause values 


SIP 


response 


QSIG Cause value 


(NOTE 6) 


415 


416 
420 
421 
423 
480 
481 


482 
483 


Elwell, 


Bad request 

Unauthorized 

Payment required 
Forbidden 

Not found 

Method not allowed 

Not acceptable 

Proxy Authentication required 
Request timeout 

Gone 

Request entity too large 
Request-URI too long 


Unsupported media type 


Unsupported URI scheme 
Bad extension 
Extension required 
Interval too brief 


Temporarily unavailable 


Call/transaction does not exist 


Loop detected 
Too many hops 


et al. 


79 


127 
127 
127 
127 
18 
41 


25 
25 


Best Current Practice 


Temporary failure 

Call rejected (NOTE 5) 
Call rejected 

Call rejected 
Unallocated number 
Service or option 
unavailable, unspecified 
Service or option not 
implemented, unspecified 
Call rejected (NOTE 5) 
Recovery on timer expiry 
Number changed 
Interworking, 
(NOTE 6) 
Interworking, 
(NOTE 6) 
Service or option not 
implemented, unspecified 
(NOTE 6) 
Interworking, 
( 

I 

( 

ile 

( 

I 


unspecified 


unspecified 


unspecified 
NOTE 6) 
nterworking, 
NOTE 6) 
nterworking, 
NOTE 6) 
nterworking, 
(NOTE 6) 

No user responding 
Temporary failure 
Exchange routing error 
Exchange routing error 


unspecified 
unspecified 


unspecified 
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485 
486 
487 
488 


500 
501 


502 
503 
504 
505 


513 


600 
603 
604 
606 


Address incomplete 


Ambiguous 
Busy here 
Request terminated 
Not Acceptable Here 


Server internal error 
Not implemented 


Bad gateway 

Service unavailable 
Gateway time-out 
Version not supported 


Message too large 


Busy everywhere 

Decline 

Does not exist anywhere 
Not acceptable 
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28 Invalid number format 
(NOTE 6) 

1 Unallocated Number 

17 User busy 

(NOTE 7) 

65 Bearer capability not 
implemented or 31 Normal, 
unspecified (NOTE 8) 

41 Temporary failure 

79 Service or option not 
implemented, unspecified 

38 Network out of order 

41 Temporary failure 

102 Recovery on timer expiry 

127 Interworking, unspecified 
(NOTE 6) 

127 Interworking, unspecified 
(NOTE 6) 

17 User busy 

21 Call rejected 

1 Unallocated number 

65 Bearer capability not 
implemented or 

31 Normal, unspecified (NOTE 8) 


NOTE 5: In some cases, it may be possible for the gateway to provide 
credentials to the SIP UAS that is rejecting an INVITE due to 


authorization failure. 
obviously it should do so and proceed with the call. 


If the gateway can authenticate itself, then 


Only if the 


gateway cannot authorize itself should the gateway clear the call in 
the OSIG network with this cause value. 


NOTE 6: 


For some response codes, 
INVITE request in order to work around the problem. 


the gateway may be able to retry the 


In particular, 


this may be the case with response codes indicating a protocol error. 
The gateway SHOULD clear the call in the QSIG network with the 
indicated cause value only if retry is not possible or fails. 


NOTE 7: 


The circumstances in which SIP response code 487 can be 


expected to arise do not require it to be mapped to a QSIG cause 


code, 
process of clearing. 


since the QSIG call will normally already be cleared or in the 
If QSIG call clearing does, however, need to be 


initiated, the default cause value should be used. 


NOTE 8: 
message, 


When the Warning header is present in a SIP 606 or 488 
the warning code should be examined to determine whether it 
is reasonable to generate cause value 65. 


This cause value should be 


generated only if there is a chance that a new call attempt with 


Elwell, 


et al. 
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different content in the Bearer capability information element will 
avoid the problem. In other circumstances, the default cause value 
should be used. 


8.4.5 Gateway-Initiated Call Clearing 


If the gateway initiates clearing of the QSIG call owing to QSIG 
timer expiry, QSIG protocol error, or use of the QSIG RESTART message 
in accordance with [2], the gateway SHALL also initiate clearing of 
the SIP call in accordance with Section 8.4.1. If this involves the 
sending of a final response to a SIP INVITE request, the gateway 
SHALL use response code 480 (Temporarily Unavailable) if optional 
QSIG timer T301 has expired or, otherwise, response code 408 (Request 
timeout) or 500 (Server internal error), as appropriate. 


If the gateway initiates clearing of the SIP call owing to SIP timer 
expiry or SIP protocol error in accordance with [10], the gateway 
SHALL also initiate clearing of the QSIG call in accordance with [2] 
using cause value 102 (Recovery on timer expiry) or 41 (Temporary 
failure), as appropriate. 


8.5. Request to Change Media Characteristics 


If after a Call has been successfully established the gateway 
receives a SIP INVITE request to change the media characteristics of 
the call in a way that would be incompatible with the bearer 
capability in use within the PISN, the gateway SHALL send back a SIP 
488 (Not Acceptable Here) response and SHALL NOT change the media 
characteristics of the existing call. 


9. Number Mapping 


In QSIG, users are identified by numbers, as defined in [1]. Numbers 
are conveyed within the Called party number, Calling party number, 
and Connected number information elements. The Calling party number 
and Connected number information elements also contain a presentation 
indicator, which can indicate that privacy is required (presentation 
restricted), and a screening indicator, which indicates the source 
and authentication status of the number. 


In SIP, users are identified by Universal Resource Identifiers (URIs) 
conveyed within the Request-URI and various headers, including the 
From and To headers specified in [10] and optionally the P-Asserted- 
Identity header specified in [14]. In addition, privacy is indicated 
by the Privacy header specified in [13]. 
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This clause specifies the mapping between QSIG Called party number, 
Calling party number, and Connected number information elements and 
corresponding elements in SIP. 


A gateway MAY implement the P-Asserted-Identity header in accordance 
with [14]. If a gateway implements the P-Asserted-Identity header, 
it SHALL also implement the Privacy header in accordance with [13]. 
If a gateway does not implement the P-Asserted-Identity header, it 
MAY implement the Privacy header. 


9.1. Mapping from QSIG to SIP 


The method used to convert a number to a URI is outside the scope of 
this specification. However, the gateway SHOULD take account of the 
Numbering Plan (NPI) and Type Of Number (TON) fields in the QSIG 
information element concerned when interpreting a number. 


Some aspects of mapping depend on whether the gateway is in the same 
trust domain (as defined in [14]) as the next hop SIP node (i.e., the 
proxy or UA to which the INVITE request is sent or from which INVITE 
request is received) to honour requests for identity privacy in the 
Privacy header. This will be network-dependent, and it is 
RECOMMENDED that gateways supporting the P-Asserted-Identity header 
hold a configurable list of next hop nodes that are to be trusted in 
this respect. 


9.1.1. Using Information from the QSIG Called Party Number Information 
Element 


When mapping a OSIG SETUP message to a SIP INVITE request, the 
gateway SHALL convert the number in the QSIG Called party number 
information to a URI and include that URI in the SIP Request-URI and 
in the To header. 


9.1.2. Using Information from the QSIG Calling Party Number Information 
Element 


When mapping a OSIG SETUP message to a SIP INVITE request, the 
gateway SHALL use the Calling party number information element, if 
present, as follows. 


If the information element contains a number, the gateway SHALL 
attempt to derive a URI from that number. Further behaviour depends 
on whether a URI has been derived and the value of the presentation 
indication. 
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9.1.2.1. No URI derived, and presentation indicator does not have value 
"presentation restricted" 


In this case (including the case where the Calling party number 
information element is absent), the gateway SHALL include a URI 
identifying the gateway in the From header. Also, if the gateway 
supports the mechanism defined in [14], the gateway SHALL NOT 
generate a P-Asserted-Identity header. 


9.1.2.2. No URI derived, and presentation indicator has value 
"presentation restricted" 


In this case, the gateway SHALL generate an anonymous From header. 
Also, if the gateway supports the mechanism defined in [14], the 
gateway SHALL generate a Privacy header field with parameter 
priv-value = "id" and SHALL NOT generate a P-Asserted-Identity 
header. The inclusion of additional values of the priv-value 
parameter in the Privacy header is outside the scope of this 
specification. 


9.1.2.3. URI derived, and presentation indicator has value 
"presentation restricted" 


If the gateway supports the P-Asserted-Identity header and trusts the 
next hop proxy to honour the Privacy header, the gateway SHALL 
generate a P-Asserted-Identity header containing the derived URI, 
SHALL generate a Privacy header with parameter priv-value = "id", and 
SHALL generate an anonymous From header. The inclusion of additional 
values of the priv-value parameter in the Privacy header is outside 
the scope of this specification. 


If the gateway does not support the P-Asserted-Identity header or 
does not trust the proxy to honour the Privacy header, the gateway 
SHALL behave as in Section 9.1.2.2. 


9.1.2.4. URI derived, and presentation indicator does not have value 
"presentation restricted" 


In this case, the gateway SHALL generate a P-Asserted-Identity header 
containing the derived URI if the gateway supports this header, SHALL 
NOT generate a Privacy header, and SHALL include the derived URI in 
the From header. In addition, the gateway MAY use S/MIME, as 
described in Section 23 of [10], to sign a copy of the From header 
included in a message/sipfrag body of the INVITE request as described 
in [20]. 
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9.1.3. Using Information from the QSIG Connected Number Information 
Element 


When mapping a OSIG CONNECT message to a SIP 200 (OK) response to an 
INVITE request, the gateway SHALL use the Connected number 
information element, if present, as follows. 


If the information element contains a number, the gateway SHALL 
attempt to derive a URI from that number. Further behaviour depends 
on whether a URI has been derived and the value of the presentation 
indication. 


9.1.3.1. No URI derived, and presentation indicator does not have value 
"presentation restricted" 


In this case (including the case where the Connected number 
information element is absent), the gateway SHALL NOT generate a 
P-Asserted-Identity header and SHALL NOT generate a Privacy header. 


9.1.3.2. No URI derived, and presentation indicator has value 
"presentation restricted" 


In this case, if the gateway supports the mechanism defined in [14], 
the gateway SHALL generate a Privacy header field with parameter 
priv-value = "id" and SHALL NOT generate a P-Asserted-Identity 
header. The inclusion of additional values of the priv-value 
parameter in the Privacy header is outside the scope of this 
specification. 


9.1.3.3. URI derived, and presentation indicator has value 
"presentation restricted" 


If the gateway supports the P-Asserted-Identity header and trusts the 
next hop proxy to honour the Privacy header, the gateway SHALL 
generate a P-Asserted-Identity header containing the derived URI and 
SHALL generate a Privacy header with parameter priv-value = "id". 

The inclusion of additional values of the priv-value parameter in the 
Privacy header is outside the scope of this specification. 


If the gateway does not support the P-Asserted-Identity header or 


does not trust the proxy to honour the Privacy header, the gateway 
SHALL behave as in Section 9.1.3.2. 
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9.1.3.4. URI derived, and presentation indicator does not have value 
"presentation restricted" 


In this case, the gateway SHALL generate a P-Asserted-Identity header 
containing the derived URI if the gateway supports this header and 
SHALL NOT generate a Privacy header. In addition, the gateway MAY 
use S/MIME, as described in Section 23 of [10], to sign a To header 
containing the derived URI, the To header being included ina 
message/sipfrag body of the INVITE response as described in [20]. 


NOTE: The To header in the message/sipfrag body may differ from the 
to header in the response’s headers. 


9.2. Mapping from SIP to QSIG 


The method used to convert a URI to a number is outside the scope of 
this specification. However, NPI and TON fields in the QSIG 
information element concerned SHALL be set to appropriate values in 
accordance with [1]. 


Some aspects of mapping depend on whether the gateway trusts the next 
hop SIP node (i.e., the proxy or UA to which the INVITE request is 
sent or from which INVITE request is received) to provide accurate 
information in the P-Asserted-Identity header. This will be 
network-dependent, and it is RECOMMENDED that gateways hold a 
configurable list of next hop nodes that are to be trusted in this 
respect. 


Some aspects of mapping depend on whether the gateway is prepared to 
use a URI in the From header to derive a number for the Calling party 
number information element. The default behaviour SHOULD be not to 
use an unsigned or unvalidated From header for this purpose, since in 
principle the information comes from an untrusted source (the remote 
UA). However, it is recognised that some network administrations may 
believe that the benefits to be derived from supplying a calling 
party number outweigh any risks of supplying false information. 
Therefore, a gateway MAY be configurable to use an unsigned or 
unvalidated From header for this purpose. 


9.2.1. Generating the QSIG Called Party Number Information Element 
When mapping a SIP INVITE request to a QSIG SETUP message, the 
gateway SHALL convert the URI in the SIP Request-URI to a number and 


include that number in the QSIG Called party number information 
element. 
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NOTE: The To header should not be used for this purpose. This is 
because re-targeting of the request in the SIP network can change the 
Request-URI but leave the To header unchanged. It is important that 
routing in the QSIG network be based on the final target from the SIP 
network. 


9.2.2. Generating the QSIG Calling Party Number Information Element 


When mapping a SIP INVITE request to a QSIG SETUP message, the 
gateway SHALL generate a Calling party number information element as 
follows. 


If the SIP INVITE request contains an S/MIME signed message/sipfrag 
body [20] containing a From header, and if the gateway supports this 
capability and can verify the authenticity and trustworthiness of 
this information, the gateway SHALL attempt to derive a number from 
the URI in that header. If no number is derived from a 
message/sipfrag body, if the SIP INVITE request contains a P- 
Asserted-Identity header, and if the gateway supports that header and 
trusts the information therein, the gateway SHALL attempt to derive a 
number from the URI in that header. If a number is derived from one 
of these headers, the gateway SHALL include it in the Calling party 
number information element and include value "network provided" in 
the screening indicator. 


If no number is derivable as described above and if the gateway is 
prepared to use the unsigned or unvalidated From header, the gateway 
SHALL attempt to derive a number from the URI in the From header. If 
a number is derived from the From header, the gateway SHALL include 
it in the Calling party number information element and include value 
"user provided, not screened" in the screening indicator. 


If no number is derivable, the gateway SHALL NOT include a number in 
the Calling party number information element. 


If the SIP INVITE request contains a Privacy header with value "id" 
in parameter priv-value and the gateway supports this header, or if 
the value in the From header indicates anonymous, the gateway SHALL 
include value "presentation restricted" in the presentation 
indicator. Based on local policy, the gateway MAY use the presence 
of other priv-values to set the presentation indicator to 
"presentation restricted". Otherwise the gateway SHALL include value 
"presentation allowed" if a number is present or "not available due 
to interworking" if no number is present. 
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If the resulting Calling party number information element contains no 
number and contains value "not available due to interworking" in the 

presentation indicator, the gateway MAY omit the information element 

from the OSIG SETUP message. 


9.2.3. Generating the QSIG Connected Number Information Element 


When mapping a SIP 2xx response to an INVITE request to a QSIG 
CONNECT message, the gateway SHALL generate a Connected number 
information element as follows. 


If the SIP 2xx response contains an S/MIME signed message/sipfrag 
[20] body containing a To header and the gateway supports this 
capability and can verify the authenticity and trustworthiness of 
this information, the gateway SHALL attempt to derive a number from 
the URI in that header. If no number is derived from a 
message/sipfrag body, if the SIP 2xx response contains a 
P-Asserted-Identity header, and if the gateway supports that header 
and trusts the information therein, the gateway SHALL attempt to 
derive a number from the URI in that header. If a number is derived 
from one of these headers, the gateway SHALL include it in the 
Connected number information element and include value "network 
provided" in the screening indicator. 


If no number is derivable as described above, the gateway SHOULD NOT 
include a number in the Connected number information element. 


If the SIP 2xx response contains a Privacy header with value "id" in 
parameter priv-value and the gateway supports this header, the 
gateway SHALL include value "presentation restricted" in the 
presentation indicator. Based on local policy, the gateway MAY use 
the presence of other priv-values to set the presentation indicator 
to "presentation restricted". Otherwise, the gateway SHALL include 
value "presentation allowed" if a number is present or "not available 
due to interworking" if no number is present. 


If the resulting Connected number information element contains no 
number and value "not available due to interworking" in the 
presentation indicator, the gateway MAY omit the information element 
from the OSIG CONNECT message. 
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10. Requirements for Support of Basic Services 


This document specifies signalling interworking for basic services 
that provide a bi-directional transfer capability for speech, 
facsimile, and modem media between the two networks. 


10.1. Derivation of QSIG Bearer Capability Information Element 


The gateway SHALL generate the Bearer Capability Information Element 
in the QSIG SETUP message based on SDP offer information received 
along with the SIP INVITE request. If the SIP INVITE request does 
not contain SDP offer information or the media type in the SDP offer 
information is only 'audio”, then the Bearer capability information 
element SHALL BE generated according to Table 3. Coding of the 
Bearer capability information element for other media types is 
outside the scope of this specification. 


In addition, the gateway MAY include a Low layer compatibility 
information element and/or High layer compatibility information in 
the QSIG SETUP message if the gateway is able to derive relevant 
information from the SDP offer information. Specific mappings are 
outside the scope of this specification. 


Table 3: Bearer capability encoding for ’audio’ transfer 


Field Value 

Coding Standard "CCITT standardized coding" (00) 
Information transfer "3,1 kHz audio" (10000) 

capability 

Transfer mode "Circuit mode" (00) 

Information transfer rate "64 Kbits/s" (10000) 

Multiplier Octet omitted 

User information layer 1 Generated by gateway based on 
protocol Information of the PISN. Supported 


values are 

"CCITT recommendation G.711 mu-law" 
(00010) 

"CCITT recommendation G.711 A-law" 
(00011) 


10.2. Derivation of Media Type in SDP 


The gateway SHALL generate SDP offer information to include in the 
SIP INVITE request based on information in the QSIG SETUP message. 
The gateway MAY take account of QSIG Low layer compatibility and/or 
High layer compatibility information elements, if present in the QSIG 
SETUP message, when deriving SDP offer information, in which case 
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specific mappings are outside the scope of this specification. 
Otherwise, the gateway shall generate SDP offer information based 
only on the Bearer capability information element in the QSIG SETUP 
message, in which case the media type SHALL be derived according to 
Table 4. 


Table 4: Media type setting in SDP based on Bearer capability 
information element 


Information transfer capability in Media type in SDP 
Bearer capability information element 

"speech" (00000) audio 

"3,1 kHz audio" (10000) audio 


Security Considerations 
1. General 


Normal considerations apply for UA use of SIP security measures, 
including digest authentication, TLS, and S/MIME as described in 
[10]. 


The translation of QSIG information elements into SIP headers can 
introduce some privacy and security concerns. For example, care 
needs to be taken to provide adequate privacy for a user requesting 
presentation restriction if the Calling party number information 
element is openly mapped to the From header. Procedures for dealing 
with this particular situation are specified in Section 9.1.2. 
However, since the mapping specified in this document is mainly 
concerned with translating information elements into the headers and 
fields used to route SIP requests, gateways consequently reveal 
(through this translation process) the minimum possible amount of 
information. 


There are some concerns, however, that arise from the other direction 
of mapping, the mapping of SIP headers to QSIG information elements, 
which are enumerated in the following paragraphs. 


.2. Calls from QSIG to Invalid or Restricted Numbers 


When end users dial numbers in a PISN, their selections populate the 
Called party number information element in the QSIG SETUP message. 
Similarly, the SIP URI or tel URL and its optional parameters in the 
Request-URI of a SIP INVITE request, which can be created directly by 
end users of a SIP device, map to that information element at a 
gateway. However, in a PISN, policy can prevent the user from 
dialing certain (invalid or restricted) numbers. Thus, gateway 
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implementers may wish to provide a means for gateway administrators 
to apply policies restricting the use of certain SIP URIs or tel 
URLs, or SIP URI or tel URL parameters, when authorizing a call from 
SIP to QSIG. 


3. Abuse of SIP Response Code 


Some additional risks may result from the mapping of SIP response 
codes to QSIG cause values. SIP user agents could conceivably 
respond to an INVITE request from a gateway with any arbitrary SIP 
response code, and thus they can dictate (within the boundaries of 
the mappings supported by the gateway) the Q.850 cause code that will 
be sent by the gateway in the resulting QSIG call clearing message. 
Generally speaking, the manner in which a call is rejected is 
unlikely to provide any avenue for fraud or denial of service (e.g., 
by signalling that a call should not be billed, or that the network 
should take critical resources off-line). However, gateway 
implementers may wish to make provision for gateway administrators to 
modify the response code to cause value mappings to avoid any 
undesirable network-specific behaviour resulting from the mappings 
recommended in Section 8.4.4. 


4. Use of the To Header URI 


This specification requires the gateway to map the Request-URI rather 
than the To header in a SIP INVITE request to the Called party number 
information element in a QSIG SETUP message. Although a SIP UA is 
expected to put the same URI in the To header and in the Request-URI, 
this is not policed by other SIP entities. Therefore, a To header 
URI that differs from the Request-URI received at the gateway cannot 
be used as a reliable indication that the call has been re-targeted 
in the SIP network or as a reliable indication of the original 
target. Gateway implementers making use of the To header for mapping 
to QSIG elements (e.g., as part of QSIG call diversion signalling) 
may wish to make provision for disabling this mapping when deployed 
in situations where the reliability of the QSIG elements concerned is 
important. 


5. Use of the From Header URI 


The arbitrary population of the From header of requests by SIP user 
agents has some well-understood security implications for devices 
that rely on the From header as an accurate representation of the 
identity of the originator. Any gateway that intends to use an 
unsigned or unverified From header to populate the Calling party 
number information element of a QSIG SETUP message should 
authenticate the originator of the request and make sure that it is 
authorized to assert that calling number (or make use of some more 
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secure method to ascertain the identity of the caller). Note that 
gateways, like all other SIP user agents, MUST support Digest 
authentication as described in [10]. Similar considerations apply to 
the use of the SIP P-Asserted-Identity header for mapping to the QSIG 
Calling party number or Connected number information element, i.e., 
the source of this information should be authenticated. Use of a 
signed message/sipfrag body to derive a QSIG Calling party number or 
Connected number information element is another secure alternative. 


11.6. Abuse of Early Media 


There is another class of potential risk that is related to the cut- 
through of the backwards media path before the call is answered. 
Several practices described in this document involve the connection 
of media streams to user information channels on inter-PINX links and 
the sending of progress description number 1 or 8 in a backward QSIG 
message. This can result in media being cut through end-to-end, and 
it is possible for the called user agent then to play arbitrary audio 
to the caller for an indefinite period of time before transmitting a 
final response (in the form of a 2xx or higher response code) to an 
INVITE request. This is useful since it also permits network 
entities (particularly legacy networks that are incapable of 
transmitting 0.850 cause values) to play tones and announcements to 
indicate Call failure or call progress, without triggering charging 
by transmitting a 2xx response. Also, early cut-through can help 
prevent clipping of the initial media when the call is answered. 
There are conceivable respects in which this capability could be used 
fraudulently by the called user agent for transmitting arbitrary 
information without answering the call or before answering the call. 
However, in corporate networks, charging is often not an issue, and 
for calls arriving at a corporate network from a carrier network, the 
carrier network normally takes steps to prevent fraud. 


The usefulness of this capability appears to outweigh any risks 
involved, which may in practice be no greater than in existing 
PISN/ISDN environments. However, gateway implementers may wish to 
make provision for gateway administrators to turn off cut-through or 
minimise its impact (e.g., by imposing a time limit) when deployed in 
situations where problems can arise. 


11.7. Protection from Denial-of-Service Attacks 


Unlike a traditional PISN phone, a SIP user agent can launch multiple 
simultaneous requests in order to reach a particular resource. It 
would be trivial for a SIP user agent to launch 100 SIP INVITE 
requests at a 100 port gateway, thereby tying up all of its ports. A 
malicious user could choose to launch requests to telephone numbers 
that are known never to answer, or, where overlap signalling is used, 
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to incomplete addresses. This could saturate resources at the 
gateway indefinitely, potentially without incurring any charges. 
Gateway implementers may therefore wish to provide means of 
restricting according to policy the number of simultaneous requests 
originating from the same authenticated source, or similar mechanisms 
to address this possible denial-of-service attack. 
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Appendix A. Example Message Sequences 


A. 


A. 
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1. Introduction 


This appendix shows some typical message sequences that can occur for 


an interworking between QSIG and SIP. It is informative. 


NOTE: For all message sequence diagrams, there is no message mapping 
between OSIG and SIP unless explicitly indicated by dotted lines. 
Also, if there are no dotted lines connecting two messages, this 
means that these are independent of each other in terms of the time 
when they occur. 


NOTE: Numbers prefixing SIP method names and response codes in the 
diagrams represent sequence numbers. Messages bearing the same 
number will have the same value in the CSeq header. 


NOTE: In these examples, SIP provisional responses (other than 100) 
are shown as being sent reliably, using the PRACK method for 
acknowledgement. 


2. Message Sequences for Call Establishment from QSIG to SIP 


Below are typical message sequences for successful call establishment 


from QSIG to SIP 
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A.2.1. QSIG to SIP, using en bloc procedures on both QSIG and SIP 


4------------------- + 
| | 
| GATEWAY | 
PISN | | IP NETWORK 
| +----- +-----—- +-----—- + | 
| | | | 
| QSIG SETUP | | 1-INVITE | 
1 | ----------------------- uti | ----------------------- >| 2 
| a | 
| QSIG CALL PROCEEDING | | 1-100 TRYING | 
3 | <----------------------- | |<----------------------- +4 
| OSIG ALERTING | | 1-180 RINGING | 
8 | <----------------------- Lassie, | <----------------------- + 5 
| | | | 
| | | 2-PRACK | 
----------------------- >| 6 
2-200 OK 
| | |<----------------------- +7 
| | | | 
| QSIG CONNECT | | 1-200 OK | 
11 | <----------------------- reer | <----------------------- + 9 
| QSIG CONNECT ACK | | 1-ACK 
12 | ----------------------- > | | ----------------------- >| 10 
| | | | 
|< >| |< >| 
| AUDIO | | AUDIO 


Figure 3: Typical message sequence for successful call establishment 
from QSIG to SIP, using en bloc procedures on both QSIG and SIP 


1 The PISN sends a QSIG SETUP message to the gateway to begin a 
session with a SIP UA. 

2 On receipt of the QSIG SETUP message, the gateway generates a SIP 
INVITE request and sends it to an appropriate SIP entity in the IP 
network based on the called number. 

3 The gateway sends a QSIG CALL PROCEEDING message to the PISN; no 
more QSIG INFORMATION messages will be accepted. 

4 The IP network sends a SIP 100 (Trying) response to the gateway. 

5 The IP network sends a SIP 180 (Ringing) response. 
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1.1 


12 


The gateway may send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

The IP network sends a SIP 200 (OK) response to the gateway to 
acknowledge the SIP PRACK request 

The gateway maps this SIP 180 (Ringing) response to a QSIG 
ALERTING message and sends it to the PISN. 

The IP network sends a SIP 200 (OK) response when the call is 
answered. 

The gateway sends a SIP ACK request to acknowledge the SIP 200 
(OK) response. 

The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 
message and sends it to the PISN. 

The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 
the OSIG CONNECT message. 
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A.2.2. QSIG to SIP, using overlap receiving on QSIG and en bloc sending 


on SIP 
4------------------------ + 
PISN | GATEWAY | IP NETWORK 
| | 
| QSIG SETUP +-------- +------- +------- + 
Y | Lo >| | | 
| QSIG SETUP ACK | | | 
2 | | | | 
| | | | 
| QSIG INFORMATION | | | 
ooo ¡8 
OSIG INFORMATION 1-INVITE 
a A d EE >|4 
| QSIG CALL PROCEEDING | | 1-100 TRYING 
5 | <-------------------------- | |<----------------------- |6 
| | | | 
| QSIG ALERTING | | 1-180 RINGING 
10 | <--------------------------|....... <----------------------- 7 
2-PRACK 
| | (aaa aan >|8 
| | | 2-200 OK | 
| | (PA E 
| QSIG CONNECT | | 1-200 OK | 
13 | <-------------------------- | cta <----------------------- pp 
| OSIG CONNECT ACK | | 1-ACK | 
14 | -------------------------- >| |----------------------- >|12 
| AUDIO | | AUDIO 
|< >| |< >| 


Figure 4: Typical message sequence for successful call establishment 
from QSIG to SIP, using overlap receiving on QSIG and en bloc sending 
on SIP 


1 The PISN sends a QSIG SETUP message to the gateway to begin a 
session with a SIP UA. The QSIG SETUP message does not contain a 
Sending Complete information element. 

2 The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 
More digits are expected. 

3 More digits are sent from the PISN within a QSIG INFORMATION 
message. 

3a More digits are sent from the PISN within a QSIG INFORMATION 
message. The QSIG INFORMATION message contains a Sending Complete 
information element. 
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The Gateway generates a SIP INVITE request and sends it to an 
appropriate SIP entity in the IP network, based on the called 
number. 

The gateway sends a QSIG CALL PROCEEDING message to the PISN; no 
more QSIG INFORMATION messages will be accepted. 

The IP network sends a SIP 100 (Trying) response to the gateway. 
The IP network sends a SIP 180 (Ringing) response. 

The gateway may send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

The IP network sends a SIP 200 (OK) response to the gateway to 
acknowledge the SIP PRACK request. 

The gateway maps this SIP 180 (Ringing) response to a QSIG 
ALERTING message and sends it to the PINX. 

The IP network sends a SIP 200 (OK) response when the call is 
answered. 

The gateway sends an SIP ACK request to acknowledge the SIP 200 
(OK) response. 

The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 
message and sends it to the PINX. 

The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 
the OSIG CONNECT message. 
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A.2.3. QSIG to SIP, using overlap procedures on both QSIG and SIP 


4---------------------- + 
PISN | GATEWAY | IP NETWORK 
| QSIG SETUP +-----—- +------—- +------ l | 
1 |------------------------- >| | | 
| | | | 
QSIG SETUP ACK 
glee ES eee po | 
| | | | 
| QSIG INFORMATION | 
3 |------------------------- > | 
| QSIG INFORMATION 1-INVITE 
3 | ------------------------- cua | ------------------------ >|4 
1-484 
| B o tases > 
| | | 1-ACK | 
| | |------------------------ dE 
| QSIG INFORMATION | | 2-INVITE 
7 |------------------------- o oi |------------------------ >|4 
2-484 
| plo > 
| | | 2-ACK | 
o O =----------------------- >|6 
| | | | 
| QSIG INFORMATION | | 
| Sending Complete IE 3-INVITE 
8 |------------------------- oe >|10 
| QSIG CALL PROCEEDING | | 3-100 TRYING 
9 \< ------------------------- | i —----------------------- |11 
| 
| QSIG ALERTING | | 3-180 RINGING 
15 | <-------------------------|....... <------------------------ 12 
| 4-PRACK 
| | 0s | eee -------------------- >|13 
| | 4-200 OK | 
| <------------------------ |14 
| QSIG CONNECT 3-200 OK | 
18 | <------------------------- | sn <------------------------ be 
| QSIG CONNECT ACK | | 3-ACK | 
19 | ------------------------- > | | ------------------------ >|17 
| AUDIO | | AUDIO | 
|< >| |< >| 
| | 
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Figure 5: Typical message sequence for successful call establishment 
from QSIG to SIP, using overlap procedures on both QSIG and SIP 


1 


18 


19 


The PISN sends a QSIG SETUP message to the gateway to begin a 
session with a SIP UA. The QSIG SETUP message does not contain a 
Sending complete information element. 

The gateway sends a QSIG SETUP ACKNOWLEDGE message to the PISN. 
More digits are expected. 

More digits are sent from the PISN within a QSIG INFORMATION 
message. 

When the gateway receives the minimum number of digits required to 
route the call, it generates a SIP INVITE request and sends it to 
an appropriate SIP entity in the IP network based on the called 
number 

Due to an insufficient number of digits, the IP network will 
return a SIP 484 (Address Incomplete) response. 

The SIP 484 (Address Incomplete) response is acknowledged. 

More digits are received from the PISN in a QSIG INFORMATION 
message. A new INVITE is sent with the same Call-ID and From 
values but an updated Request-URI. 

More digits are received from the PISN in a QSIG INFORMATION 
message. The QSIG INFORMATION message contains a Sending Complete 
information element. 

The gateway sends a QSIG CALL PROCEEDING message to the PISN; no 
more information will be accepted. 

The gateway sends a new SIP INVITE request with an updated 
Request-URI field. 

The IP network sends a SIP 100 (Trying) response to the gateway. 
The IP network sends a SIP 180 (Ringing) response. 

The gateway may send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

The IP network sends a SIP 200 (OK) response to the gateway to 
acknowledge the SIP PRACK request. 

The gateway maps this SIP 180 (Ringing) response to a QSIG 
ALERTING message and sends it to the PISN. 

The IP network sends a SIP 200 (OK) response when the call is 
answered. 

The gateway sends a SIP ACK request to acknowledge the SIP 200 
(OK) response. 

The gateway maps this SIP 200 (OK) response to a QSIG CONNECT 
message. 

The PISN sends a QSIG CONNECT ACKNOWLEDGE message in response to 
the OSIG CONNECT message. 
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A.3. 


Message sequences for call establishment from SIP to QSIG 


Below are typical message sequences for successful call establishment 
from SIP to QSIG 


A.3.1. SIP to QSIG, using en bloc procedures 
4+---------------------- + 
IP NETWORK GATEWAY PISN 
| $------- +------- +-----—- + | 
| | | | 
| | | | 
| 1-INVITE | | QSIG SETUP | 
1 |------------------------- uta | ------------------------ >13 
1-100 TRYING OSIG CALL PROCEEDING 
2 |<------------------------- <------------------------ 4 
| 1-180 RINGING | | QSIG ALERTING 
6 |<------------------------- EEFT |<------------------------ |5 
| | | | 
| | | | 
2-PRACK 
y | e | | | 
| 2-200 OK | | | 
8 |<------------------------- | | | 
| 1-200 OK | | QSIG CONNECT | 
11 | <------------------------- Mie eats | <------------------------ |9 
| 1-ACK | | OSIG CONNECT ACK | 
12 | ------------------------- > | | ------------------------ >|10 
| AUDIO | | AUDIO | 
|< >| |< >| 
| | 


Figure 6: Typical message sequence for successful call establishment 
from SIP to QSIG, using en bloc procedures 


1 
2 
3 


The IP network sends a SIP INVITE request to the gateway. 

The gateway sends a SIP 100 (Trying) response to the IP network. 
On receipt of the SIP INVITE request, the gateway sends a QSIG 
SETUP message. 

The PISN sends a OSIG CALL PROCEEDING message to the gateway. 

A QSIG ALERTING message is returned to indicate that the end user 
in the PISN is being alerted. 

The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) 
response. 
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7 The IP network can send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

8 The gateway sends a SIP 200 (OK) response to acknowledge the SIP 
PRACK request. 

9 The PISN sends a QSIG CONNECT message to the gateway when the call 
is answered. 

10 The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 
acknowledge the QSIG CONNECT message. 

11 The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 

12 The IP network, upon receiving a SIP INVITE final response (200), 
will send a SIP ACK request to acknowledge receipt. 
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A.3.2. SIP to QSIG, using overlap receiving on SIP and en bloc sending 


on QSIG 
$ + 
IP NETWORK | GATEWAY | PISN 
| | 
| 1-INVITE +------- +------- +------ + 
1 | -=--===--~---=----------- >| | | 
1-484 
gs eee Po | 
| 1-ACK | | | 
3 |------------------------- >| | | 
| 2-INVITE | | | 
1 |------------------------- >| | | 
| 2-484 | | | 
2 |<------------------------- 
2- ACK 
3 | ------------------------- >| | | 
| 3-INVITE | | QSIG SETUP | 
4 |------------------------- DES ASE | ------------------------ >|6 
| 3-100 TRYING | | QSIG CALL PROCEEDING | 
5 |<------------------------- <------------------------ 7 
3-180 RINGING OSIG ALERTING 
9 |<------------------------- [bore otra | <------------------------ |8 
| | | | 
| | | | 
| 4-PRACK | | | 
10 | ------------------------- > 
4-200 OK 
11 |<------------------------- | | | 
| 3-200 OK | | QSIG CONNECT | 
14 | <------------------------- (ES | <------------------------ |12 
| | | | 
3-ACK QSIG CONNECT ACK 
15 | ------------------------- >| 0 | eee -------------------- >|13 
| AUDIO | AUDIO 
| 
| 


| | 
< >| |< >| 

| | | 
Figure 7: Typical message sequence for successful call establishment 


from SIP to QSIG, using overlap receiving on SIP and en bloc sending 
on QSIG 


1 The IP network sends a SIP INVITE request to the gateway. 

2 Due to an insufficient number of digits, the gateway returns a SIP 
484 (Address Incomplete) response. 

3 The IP network acknowledges the SIP 484 (Address Incomplete) 
response. 
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10 


11 


12 


13 


14 
IBS 


The IP network sends a new SIP INVITE request with the same Call- 
ID and updated Request-URI. 

The gateway now has all the digits required to route the call to 
the PISN. The gateway sends back a SIP 100 (Trying) response. 
The gateway sends a QSIG SETUP message. 

The PISN sends a QSIG CALL PROCEEDING message to the gateway. 

A QSIG ALERTING message is returned to indicate that the end user 
in the PISN is being alerted. 

The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) 
response. 

The IP network can send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

The gateway sends a SIP 200 (OK) response to acknowledge the SIP 
PRACK request. 

The PISN sends a QSIG CONNECT message to the gateway when the call 
is answered. 

The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 
acknowledge the CONNECT message. 

The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 
The IP network, upon receiving a SIP INVITE final response (200), 
will send a SIP ACK request to acknowledge receipt. 
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Sis 


497 
SIP to QSIG, 
+ 
IP NETWORK | 
| 
| 1-INVITE 
—-----------------------+- > | 
| 1-484 | 
< SS Ste A A AS, 
1-ACK 
| ------------------------- >| 
| 2-INVITE | 
|------------------------- >| 
| 2-100 TRYING | 
|<------------------------- | 
3- INVITE 
m l 
| 3-100 TRYING | 
Peg a | 
| 3-180 RINGING | 
< EEE EEEE 
2-484 
|<------------------------- | 
| 2-ACK | 
|------------------------- >| 
| 4-PRACK | 
A A A a A A AA > 
4-200 OK 
|<------------------------- | 
| 3-200 OK | 
| o | 
| | 
3-ACK 
A l 
| AUDIO | 
|< >| 
| | 
gure 8: 


The 
Due 


484 (Address Incomplete) response. 
The IP network acknowledges the SIP 484 
response. 


et al. 


Interworking between SIP and QSIG 


Best Current Practice 


using overlap procedures on both SIP and QSIG 


+ 
| PISN 
| 
+------ + | 
| | 
| | 
| | 
| QSIG SETUP | 
|------------------------ >|6 
| QSIG SETUP ACK 
| <------------------------ |7 
QSIG INFORMATION 
------------------------ >|10 
| 
| QSIG CALL PROCEEDING | 
|<------------------------ |11 
| QSIG ALERTING | 
<------------------------ i 
| | 
| | 
| | 
| | 
| | 
| QSIG CONNECT | 
|<------------------------ |18 
| | 
QSIG CONNECT ACK 
------------------------ >|19 
| AUDIO 
|< 


Typical message sequence for successful call establishment 
from SIP to QSIG, using overlap procedures on both SIP and QSIG 
IP network sends a SIP INVITE request to the gateway. 

to an insufficient number of digits, 


(Address Incomplete) 


May 2006 


the gateway returns a SIP 
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20 
21 


The IP network sends a new SIP INVITE request with the same 
Call-ID and updated Request-URI. 

The gateway now has all the digits required to route the call to 
the PISN. The gateway sends back a SIP 100 (Trying) response to 
the IP network. 

The gateway sends a QSIG SETUP message. 

The PISN needs more digits to route the call and sends a QSIG 
SETUP ACKNOWLEDGE message to the gateway. 

The IP network sends a new SIP INVITE request with the same 
Call-ID and From values and updated Request-URI. 

The gateway sends back a SIP 100 (Trying) response to the IP 
network. 

The gateway maps the new SIP INVITE request to a QSIG INFORMATION 
message. 

The PISN has all the digits required and sends back a QSIG CALL 
PROCEEDING message to the gateway. 

A QSIG ALERTING message is returned to indicate that the end user 
in the PISN is being alerted. 

The gateway maps the QSIG ALERTING message to a SIP 180 (Ringing) 
response. 

The gateway sends a SIP 484 (Address Incomplete) response for the 
previous SIP INVITE request. 

The IP network acknowledges the SIP 484 (Address Incomplete) 
response. 

The IP network can send back a SIP PRACK request to the IP network 
based on the inclusion of a Require header or a Supported header 
with option tag 100rel in the initial SIP INVITE request. 

The gateway sends a SIP 200 (OK) response to acknowledge the SIP 
PRACK request. 

The PISN sends a OSIG CONNECT message to the gateway when the call 
is answered. 

The gateway sends a QSIG CONNECT ACKNOWLEDGE message to 
acknowledge the QSIG CONNECT message. 

The QSIG CONNECT message is mapped to a SIP 200 (OK) response. 
The IP network, upon receiving a SIP INVITE final response (200), 
will send a SIP ACK request to acknowledge receipt. 
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A.4. 


Message Sequence for Call Clearing from QSIG to SIP 


Below are typical message sequences for Call Clearing from QSIG to 
SIP 


A.4. 


QSIG to SIP, subsequent to call establishment 


GATEWAY 
PISN | | IP NETWORK 


+ 

| | 
| 

| 


| QSIG DISCONNECT 2- BYE 

1 | ----------------------- >|...... |----------------------- >|4 
| QSIG RELEASE | 2-200 OK 

2 | <----------------------- | <----------------------- [5 
| QSIG RELEASE COMP 

3|----------------------- > 


Figure 9: Typical message sequence for call clearing from QSIG to 
SIP, subsequent to call establishment 


1 
2 


The PISN sends a QSIG DISCONNECT message to the gateway. 

The gateway sends back a QSIG RELEASE message to the PISN in 
response to the QSIG DISCONNECT message. 

The PISN sends a QSIG RELEASE COMPLETE message in response. All 
PISN resources are now released. 

The gateway maps the QSIG DISCONNECT message to a SIP BYE request. 
The IP network sends back a SIP 200 (OK) response to the SIP BYE 
request. All IP resources are now released. 
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A.1.2. QSIG to SIP, during establishment of a call from SIP to QSIG 


PISN | IP NETWORK 


Figure 10: Typical message sequence for call clearing from QSIG to 
SIP, during establishment of a call from SIP to QSIG (gateway has 
not sent a final response to the SIP INVITE request) 


1 The PISN sends a QSIG DISCONNECT message to the gateway 

2 The gateway sends back a OSIG RELEASE message to the PISN in 
response to the QSIG DISCONNECT message 

3 The PISN sends a QSIG RELEASE COMPLETE message in response. All 
PISN resources are now released. 

4 The gateway maps the QSIG DISCONNECT message to a SIP 4xx-6xx 


response 
5 The IP network sends back a SIP ACK request in response to the SIP 
4xx-6xx response. All IP resources are now released 
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A.4. 


3. 


QSIG to SIP, during establishment of a call from QSIG to SIP 


4------------------- + 
| | 
| GATEWAY | 
PISN | | IP NETWORK 
| +----—- +-----—- +-----—- + | 
| | | | 
| QSIG DISCONNECT | | 1- CANCEL 
1 | ----------------------- ST eho) oes | ----------------------- >|4 
| QSIG RELEASE | | 1-487 Request Terminated | 
2 | <----------------------- | |<----------------------- |5 
| OSIG RELEASE COMP | | 
3 | ----------------------- > | | 1- ACK | 
| IO il 
| | | 1- 200 OK | 
| | | <---~---=--=-----==--=-- |7 
| | 


Figure 11: Typical message sequence for call clearing from QSIG to 
SIP, during establishment of a call from QSIG to SIP (gateway has 
received a provisional response to the SIP INVITE request but not a 
final response) 


1 
2 


The PISN sends a QSIG DISCONNECT message to the gateway. 

The gateway sends back a QSIG RELEASE message to the PISN in 
response to the QSIG DISCONNECT message. 

The PISN sends a QSIG RELEASE COMPLETE message in response. All 
PISN resources are now released. 

The gateway maps the QSIG DISCONNECT message to a SIP CANCEL 
request (subject to receipt of a provisional response, but not of 
a final response). 

The IP network sends back a SIP 487 (Request Terminated) response 
to the SIP INVITE request. 

The gateway, on receiving a SIP final response (487) to the SIP 
INVITE request, sends back a SIP ACK request to acknowledge 
receipt. 

The IP network sends back a SIP 200 (OK) response to the SIP 
CANCEL request. All IP resources are now released. 
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A.5. Message Sequence for Call Clearing from SIP to QSIG 


Below are typical message sequences for Call Clearing from SIP to 
QSIG 


Ais ot ME SIP to QSIG, subsequent to call establishment 


4------------------- + 
GATEWAY 
IP NETWORK | | PISN 
| +----- +-----—- +-----—- + | 
| | | | 
| | | | 
| 2- BYE | | QSIG DISCONNECT | 
1 | ----------------------- >|... e. e |----------------------- >|3 
QSIG RELEASE 
| | <---~------------------- |a 
2-200 OK | | QSIG RELEASE COMP | 
| 
| 
| 


| 
| 
2 | <----------------------- | 
| 
| 


Figure 12: Typical message sequence for call clearing from SIP to 
QSIG, subsequent to call establishment 


1 The IP network sends a SIP BYE request to the gateway. 

2 The gateway sends back a SIP 200 (OK) response to the SIP BYE 
request. All IP resources are now released. 

3 The gateway maps the SIP BYE request to a QSIG DISCONNECT message. 

4 The PISN sends back a QSIG RELEASE message to the gateway in 
response to the QSIG DISCONNECT message. 

5 The gateway sends a OSIG RELEASE COMPLETE message in response. 
All PISN resources are now released. 
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A.5.2. SIP to QSIG, during establishment of a call from QSIG to SIP 


IP NETWORK | | PISN 


| 1- 4XX / 6XX 


1 | ----------------------- EA | ----------------------- >|3 
| | OSIG RELEASE | 

| |<----------------------- |a 
1- ACK | | OSIG RELEASE COMP | 


| 
| 
| 
2 | <----------------------- | |----------------------- >|5 
| 


Figure 13: Typical message sequence for call clearing from SIP to 
QSIG, during establishment of a call from QSIG to SIP (gateway has 
not previously received a final response to the SIP INVITE request) 


1 The IP network sends a SIP 4xx-6xx response to the gateway. 

2 The gateway sends back a SIP ACK request in response to the SIP 
4xx-6xx response. All IP resources are now released. 

3 The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 
message. 

4 The PISN sends back a QSIG RELEASE message to the gateway in 
response to the QSIG DISCONNECT message. 

5 The gateway sends a QSIG RELEASE COMPLETE message in response. 
All PISN resources are now released. 
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3. SIP to QSIG, during establishment of a call from SIP to QSIG 


4------------------- + 
| | 
| GATEWAY | 
IP NETWORK | | PISN 
| +----—- +-----—- +-----—- + | 
| | | | 
| 1- CANCEL | | QSIG DISCONNECT | 
1 | ----------------------- | EA | ----------------------- >|4 
| | | OSIG RELEASE | 
| | | <----------=------------ ls 
|1-487 Request Terminated| | QSIG RELEASE COMP | 
2 | <----------------------- | |----------------------- >16 
| ack o | 
3 | ----------------------- >| | | 
| | | | 
| 1- 200 OK | | | 
4 | <----------------------- | | | 
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response to the SIP CANCEL 
All IP resources are now released. 


The gateway maps the SIP 4xx-6xx response to a QSIG DISCONNECT 


The PISN sends back a QSIG RELEASE message to the gateway in 
response to the QSIG DISCONNECT message. 
The gateway sends a QSIG RELEASE COMPLETE message in response. 
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The 
The gateway sends back a SIP 487 
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The IP network, 
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The gateway sends back a SIP 200 
request. 
message. 
All PISN resources are now released. 
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